Summary

• reject differently-shaped component schemas that share a name while exported apps are merged
• reuse CollectedMetadata::check_duplicate_schema_names() so identical definitions retain the existing silent deduplication behavior
• identify the parent/merged app origins in the diagnostic and span the error to the incoming app path in merge = [...]

Verified pre-change behavior

The pre-change behavior was silent first-wins, not last-wins. OpenApi::merge preserves the schema already present in self; compile-time app assembly starts with the parent spec and folds merged apps in declaration order. Therefore the parent wins over children, and among children the earlier entry wins over a later collision.

I verified this against the existing vespera_core merge contract before changing the macro. In the reported reproduction, Plugin A was merged before Plugin B, so both /api/example/items/ and /memo/collision-probe remained in paths, but components.schemas.ExampleItem retained only Plugin A's { id, name, description, createdAt } shape. Plugin B's runtime response { collisionMarker, count } was silently documented with Plugin A's incompatible schema.

The merge boundary only has each exported app's OpenAPI sidecar and the syn::Path entries supplied to vespera!(merge = [...]); original struct spans from child crates are no longer available. The diagnostic therefore points at the conflicting incoming app path and names both best-available origins (for example, plugin_a::PluginA and plugin_b::PluginB).

Tests

• cargo test --workspace
• bun run lint
• regression coverage for conflicting child schemas, identical shared schemas, and a schema defined once

The changepack records this as a minor vespera_macro change because previously silent collisions can now fail existing builds.